-
Notifications
You must be signed in to change notification settings - Fork 118
tweak(font): Redesign and fix the font scaling for large resolutions and non 4:3 aspect ratios #1466
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: main
Are you sure you want to change the base?
tweak(font): Redesign and fix the font scaling for large resolutions and non 4:3 aspect ratios #1466
Conversation
|
Compared to scaling off the smallest side of the image, this does not work the moment you compare between different aspect ratios where the resolutions have the same height or width. in 2560x1080 the font is a size larger for every font compared to 1920x1080. at 3440x1440 the font is larger than 2560x1440 etc. By scaling off the smallest edge the font size is consistent between different aspect ratios. If you were to theoretically compare |
|
I do not know what this means. |
This method does not work since you are scaling based on both display axis. And due to this, it does not keep the font size consistant at increasing aspect ratio. |
|
Yes this is intended. |
But it is not the correct behaviour that we should have, because it means less text will fit vertically if you had the same 1080 height and the screen gets wider. Fonts get larger in both dimensions as their point increases. It will also make fonts not scale properly to other UI elements as the screen gets wider as well. |
|
Yes but since the screen is wider or higher, there will be more room to fit texts. I am not concerned about the "technical" correctness of it, if it just looks good in the UI that the game has. Can you show an example where this does not look correct with the proposed change? |
|
it introduces inconsistant behaviour as the screen aspect ratio changes. If a UI element is created that scales with the vertical resolution and someone sets a font for the height of that element, at a different screeen aspect the font will grow or shrink and not be consistant for that display element. At a fixed screen height, the font should be consistent and remain the same size, even as the width of the screen changes. |
How do you know this? The font sizes in Generals UI are much smaller than the buttons and things they are contained in. So there is enough room to increase their sizes. This change gives a balanced growth for aspects > 1.33 < 2.00 I suggest take a look at it ingame and see how the UI looks, not the technical expectation. |
|
i am considering the behaviour and use of fonts within game now and in future, when UI changes are made or within MODs etc. So you have to consider the technicalities of how this affects font handling in general. The font scaling also affects more than just the UI elements, it also affects ingame text too etc. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
On a different note, this also breaks the current implementation of control bar pro at higher than 2k.
I made this tweak in the past for my test builds.
It would require control bar pro to be updated with a parralel SH compatible version that removes the new fonts for 2k+ resolutions
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Fixed.
3a95cef to
01dc8cb
Compare
Ok. I have implemented two new scaling methods now: Strict and Balanced. The Balanced method looks closer to the Classic method which is far more important for the original UI and smooth adoption than forcing the Strict method. Note that Classic looks NOT broken in 1920x1080. The Strict method can be opt-in for new UI's that prefer it. And Control Bar Pro will automatically enable the Classic scaling method. |
|
Honestly this is still just over complicating something that is pretty straightforward. If the font sizing is considered a little small we can adjust the |
|
I suggest test it in game if not yet done. To me this change looked good whereas #1442 did not. |
I have been using 1442 in test builds for the past few months now, it looks consistent and right at all resolutions and aspect ratios. And it matches how text looks when comparing various UI or ingame elements to original 4:3 resolutions and is how it would have looked if 16:9 had been officially supported and the bug had not existed. No one using the test builds has complained that the font size is a problem, if anything they notice that text fits better and more shows in replay or map lists. yes the text is smaller than how it shows in retail when people use resolutions beyond what the game engine officially supported, but that is because of a bug rather than because of how it was meant to look. |
I am raising it to be a problem. Does my feedback not matter? I have played with 1920 x 1080 for many years and this font size reduction is very noticable for me and not all positive. For example look at the small money value in game. It is more difficult to see. I think it is a mistake to default to Strict font scaling until we tweak UI more in data. |
|
I also think the implementation in this PR is too complicated. How about with use the strict algo and apply a constant size increase (because players are now used to the bigger size). |
|
I have altered the implementation of #1442 so it now rescales It produces fonts closer to 1080p retail while maintaining uniform font scaling across all resolutions and aspect ratios. |
|
We will need to find some compromise. |
GeneralsMD/Code/GameEngine/Source/GameClient/GlobalLanguage.cpp
Outdated
Show resolved
Hide resolved
…and non 4:3 aspect ratios
01dc8cb to
2e6703e
Compare
|
I have made another pass on this. CLASSIC_NO_CEILING is now the default font scaling method. |
| if (aspect > 2.0f) | ||
| { | ||
| // Recompute width at aspect=2 | ||
| w = 2.0f * h; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I still don't think this is quite right, it would be better to clamp it so aspects larger than 1.8 will scale the fonts the same as their 16:9 equivalent.
if we have 1920x1080 then the 2560x1080 resolution will get the same font scaling since the height is the same for both resolutions. This should also then work the same for 3840x1080 etc
the computation is also then scaled w = 1.8f * h; etc
I would then be okay with this being the default method as it should scale with roughtly the same retail looking font sizes across all current resolutions.




This change is an alternative implementation for #1442.
The disadvantage of #1442 is that the proposed new font scaling for 1920 x 1080 is noticably smaller than the original font scaling: 21%. This is an inconvenience, because 1920 x 1080 and other 16:9 resolutions are the most popular resolutions to play with and their font scales are generally ok.
This change implements 3 new font scaling methods, on top of CLASSIC:
The new scaling methods can be set in Language.ini with the
ResolutionFontSizeMethodfield.CLASSIC_NO_CEILING
CLASSIC_NO_CEILING is the new default and scales alright in 4k.
CLASSIC
The CLASSIC scaling method is auto selected for the current generations of Control Bar Pro addons, because they do have custom font scaling for 2560 x 1440 and 3840 x 2160.
STRICT
The STRICT scaling method scales by the minimum growth of width or height. Identical to what #1442 does.
BALANCED
The BALANCED scaling method scales by the average growth of width and height, evenly weighted. It scales well in different resolutions and aspect ratios. In 1920x1080 the font size will be just 11% smaller than originally.
TODO